E0277: suggest dereferencing function arguments in more cases #133292
Conversation
|
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
rustbot
added
S-waiting-on-review
| // reference, `ty` is `Copy`, or we're moving out of a (potentially nested) `Box`. | ||
| let can_deref = is_under_ref.is_some() | ||
| || self.type_is_copy_modulo_regions(obligation.param_env, ty) | ||
| || ty.is_numeric() // for inference vars (presumably but not provably `Copy`) |
There was a problem hiding this comment.
The ty.is_numeric() case is admittedly a hack for tests/ui/traits/suggest-dereferences/suggest-dereferencing-receiver-argument.rs, since it wants a deref suggestion for an &{integer}. I think a slightly more principled (still hacky) way to do this could be to walk through base_ty and add Copy bounds to the ParamEnv for any numeric inference vars. It should maybe also downgrade the suggestion to MaybeIncorrect if any type inference vars are present. {integer}: Sized does appear to be provable already, at least.
|
r? compiler |
This unifies and generalizes some of the logic in
TypeErrCtxt::suggest_dereferencesso that it will suggest dereferencing arguments to function/method calls in order to satisfy trait bounds in more cases.Previously it would only fire on reference types, and it had two separate cases (one specifically to get through custom
Derefimpls when passing by-reference, and one specifically to catch #87437). I've based the new checks loosely on what's done forE0308inFnCtxt::suggest_deref_or_ref: it will suggest dereferences to satisfy trait bounds whenever the referent isCopy, is boxed (& so can be moved out of the boxes), or is being passed by reference.This doesn't make the suggestion fire in contexts other than function arguments or binary operators (which are in a separate case that this doesn't touch), and doesn't make it suggest a combination of
&-removal and dereferences. Those would require a bit more restructuring, so I figured just doing this would be a decent first step.Closes #90997